Output Strategies

In a Nutshell

Strategy?

Why is it called Strategy? It describes how the output process should go about returning the information that was requested
The output strategy object tells Geoserver how to proceede when returning the data.

A Strategy is also a design pattern that is defined in the Gang of Four Design Patterns book (ISBN 0201633612). What it essentially does, is allow the user to plug in their own method of performing a specific task. So what Geoserver does is read the web.xml file, see what strategy you want to use ('speed' in our example), and plug it into the output response process.

Structure of Strategy Objects

Configuration

Look in your web.xml file.

<context-param>
    <param-name>serviceStratagy</param-name>
    <!-- Meaning of the different values :
         BUFFER
         - stores the entire response in memory first, before sending it off to
           the user (may run out of memory)

         SPEED
         - outputs directly to the response (and cannot recover in the case of an
           error)

         FILE
         - outputs to the local filesystem first, before sending it off to the user
      -->
    <param-value>SPEED</param-value>
  </context-param>

Options

There are currently four implemented serviceStrategies. Two of them can probably be combined in to one, but each takes a bit of a different approach to how we return data. Why? The main reason is because the fastest way to return data, by streaming out directly, is not always the 'best'. The big problem is that we can't properly implement the OGC specifications, since they require every error to be reported properly. If we've already started streaming data and then get an error then there's no way to notify the client. So what we do instead is write to various buffers to test out the response before actually sending it.

Buffer writes the response to a memory buffer before returning it to the client. This is not as fast as it could go, but is quite fast, since it's just held in memory. The downside is that it doesn't scale well, with a large response or many requests at once this quickly takes up too much memory. It's great for testing, but we don't recommend it for any production systems.

Speed is the fastest strategy, as its name implies. It doesn't bother to do any error checking, just connects the stream straight to the client. If the system is well tested this can be good to use in production. But if there are errors during the response then clients won't know what went wrong. But client errors should never cause problems, it's only when streaming, which implies either an error in the programming of GeoServer, or in the data.

Disk is not as fast as Buffer, as it writes the response out to disk instead of memory. This means it does well with large responses, and it will always return the proper error. The problem is that it can be slow.

Partial Buffer is a compromise between Speed and Buffer. It lets users specify how big they want the memory buffer to be. Usually the buffer's are pretty small, which means there could be some errors deep in the response that cause problems. But the majority of errors that mess up responses happen within the first bit anyways, sql being malformed or some such, so this strategy is generally pretty safe. It's what GeoServer ships by default.